VPLAY-12164 Http 404 for mpd while channel change #845

sayanurag · 2026-01-13T10:12:43Z

Reason for change: Moving the Teardown operation before the mpd update release cause some delay and results in more Http 404 errors.
Test Procedure: updated in ticket
Risks: Low

Reason for change: Moving the Teardown operation before the mpd update release cause some delay and results in more Http 404 errors. Test Procedure: updated in ticket Risks: Low Signed-off-by: Anurag Krishnan <akrish513@cable.comcast.com>

Copilot

Pull request overview

This PR addresses HTTP 404 errors occurring during channel changes by moving the MPD downloader release operation to happen immediately after stream abstraction deletion, rather than waiting for the complete Stop() sequence to finish.

Changes:

Added conditional MPD downloader release inside TeardownStream() when disableDownloads is true
The early release prevents unnecessary MPD update requests that would fail with HTTP 404 during channel transitions

priv_aamp.cpp

jfagunde · 2026-01-13T17:29:14Z

priv_aamp.cpp

+		// stop the mpd update immediately after Stream abstraction delete
+		if(mMPDDownloaderInstance != nullptr)
+		{
+			mMPDDownloaderInstance->Release();


Can this call be removed from other places since it is done here? I.e. from PrivateInstanceAAMP::detach() and PrivateInstanceAAMP::Stop()

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 3 comments.

Copilot · 2026-01-20T11:12:26Z

priv_aamp.cpp

+		if(mMPDDownloaderInstance != nullptr)
+		{
+			mMPDDownloaderInstance->Release();


The new code block accesses mMPDDownloaderInstance without holding mLock. While this appears consistent with similar patterns elsewhere in the codebase (e.g., Stop() at line 8091 and detach() at line 7110), consider whether explicit locking is needed here for thread safety. The Release() method has internal locking via mMPDDnldMutex, but the pointer access itself is not synchronized. If mMPDDownloaderInstance can be deleted or modified from another thread during teardown, this could lead to a race condition.

Suggested change

if(mMPDDownloaderInstance != nullptr)

{

mMPDDownloaderInstance->Release();

AampMPDDownloader *mpdDownloader = NULL;

lock.lock();

mpdDownloader = mMPDDownloaderInstance;

lock.unlock();

if(mpdDownloader != NULL)

{

mpdDownloader->Release();

Copilot · 2026-01-20T11:12:26Z

priv_aamp.cpp

+	if(disableDownloads)
+	{
+		// stop the mpd update immediately after Stream abstraction delete
+		if(mMPDDownloaderInstance != nullptr)
+		{
+			mMPDDownloaderInstance->Release();
+		}
+	}


This change introduces a potential double-call to mMPDDownloaderInstance->Release(). When TeardownStream(true, true) is called from Stop() (line 8088), this new code will call Release(), and then Stop() calls it again at line 8091-8094. While Release() is idempotent (protected by the mReleaseCalled flag), consider whether the duplicate call in Stop() should be removed to avoid confusion and make the cleanup flow clearer.

Suggested change

if(disableDownloads)

{

// stop the mpd update immediately after Stream abstraction delete

if(mMPDDownloaderInstance != nullptr)

{

mMPDDownloaderInstance->Release();

}

}

// Note: MPD downloader Release() is handled by the caller (e.g. Stop())

// to avoid duplicate Release() calls when TeardownStream(true, true) is

// invoked from Stop().

Copilot · 2026-01-20T11:12:26Z

priv_aamp.cpp

+	if(disableDownloads)
+	{
+		// stop the mpd update immediately after Stream abstraction delete
+		if(mMPDDownloaderInstance != nullptr)
+		{
+			mMPDDownloaderInstance->Release();
+		}
+	}


The code uses a raw pointer (mMPDDownloaderInstance) with manual lifecycle management (new at line 5628, SAFE_DELETE at line 8199). Consider refactoring to use a smart pointer (e.g., std::unique_ptr) to follow modern C++ RAII principles and improve memory safety. This would make ownership semantics clearer and eliminate the possibility of memory leaks.

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 3 comments.

Copilot · 2026-01-21T20:52:14Z

priv_aamp.cpp

+
+	if(disableDownloads)
+	{
+		// stop the mpd update immediately after Stream abstraction delete


The comment "stop the mpd update immediately after Stream abstraction delete" is copied from line 8104 in the Stop() function but doesn't explain the rationale for this specific placement.

The comment should clarify:

Why the MPD downloader needs to be released at this point in TeardownStream

How this placement helps reduce HTTP 404 errors during channel changes (as mentioned in the PR description)

The relationship with the existing Release() call in Stop() at line 8107

This will help future maintainers understand the design decision and prevent accidental removal or duplication.

Suggested change

// stop the mpd update immediately after Stream abstraction delete

/*

* DASH-specific teardown: explicitly stop MPD updates as soon as the

* stream abstraction has been stopped/deleted.

*

* Rationale:

* - When changing channels, the MPD downloader may still be running

* background manifest refreshes based on the old stream abstraction

* state (periods, adaptation sets, timelines, etc.).

* - If the service reuses the same MPD URL for the new channel or if

* the old MPD becomes invalid while those refreshes are still in

* flight, the downloader can issue requests that no longer match

* the server state, leading to transient HTTP 404s during channel

* changes (as described in the PR).

*

* By releasing the MPD downloader here, immediately after

* mpStreamAbstractionAAMP is torn down and only when downloads are

* being disabled, we ensure that no further MPD refreshes are issued

* based on stale stream state.

*

* Note:

* - There is also a later mMPDDownloaderInstance->Release() call in

* Stop() (line 8107) which serves as a final safety net / global

* cleanup.

* - This earlier Release() in TeardownStream is the intentional,

* protocol-aware shutdown point required to avoid the 404 bursts

* seen on rapid channel changes; the Stop()-level call must not be

* treated as a replacement for this one.

*/

Copilot · 2026-01-21T20:52:15Z

priv_aamp.cpp

+	if(disableDownloads)
+	{
+		// stop the mpd update immediately after Stream abstraction delete
+		if(mMPDDownloaderInstance != nullptr)
+		{
+			mMPDDownloaderInstance->Release();
+		}
+	}


This new code path (calling mMPDDownloaderInstance->Release() inside TeardownStream when disableDownloads is true) lacks test coverage.

The existing TeardownStream tests in test/utests/tests/PrivAampTests/PrivAampTests.cpp (TeardownStreamTest, TeardownStreamTest_1, TeardownStreamTest_2) do not verify:

That Release() is called when disableDownloads=true

That Release() is NOT called when disableDownloads=false

The interaction with mMPDDownloaderInstance being null vs non-null

Add test cases to verify this behavior, especially for the scenario described in the ticket (channel change causing HTTP 404 errors).

Copilot · 2026-01-21T20:52:15Z

priv_aamp.cpp

+	if(disableDownloads)
+	{
+		// stop the mpd update immediately after Stream abstraction delete
+		if(mMPDDownloaderInstance != nullptr)
+		{
+			mMPDDownloaderInstance->Release();
+		}
+	}


This change introduces a potential duplicate Release() call when TeardownStream is invoked from the Stop() function. At line 8102, Stop() calls TeardownStream(true, true) with disableDownloads=true, which will trigger this new Release() call. Then at line 8107, Stop() calls mMPDDownloaderInstance->Release() again.

While Release() is idempotent (protected by the mReleaseCalled flag), this duplication suggests a design issue. Consider one of the following solutions:

Remove the Release() call at line 8107 in Stop() since it's now handled in TeardownStream

Remove this new code and keep the existing Release() call in Stop() at line 8107

Add a clear comment explaining why Release() is called in both locations if both are truly needed

The PR description mentions "Moving the Teardown operation before the mpd update release cause some delay" which suggests option 1 (removing the call from Stop()) may be the intended solution.

Suggested change

if(disableDownloads)

{

// stop the mpd update immediately after Stream abstraction delete

if(mMPDDownloaderInstance != nullptr)

{

mMPDDownloaderInstance->Release();

}

}

Copilot AI review requested due to automatic review settings January 13, 2026 10:12

sayanurag requested a review from a team as a code owner January 13, 2026 10:12

Copilot started reviewing on behalf of sayanurag January 13, 2026 10:13 View session

Copilot AI reviewed Jan 13, 2026

View reviewed changes

priv_aamp.cpp Show resolved Hide resolved

priv_aamp.cpp Show resolved Hide resolved

jfagunde reviewed Jan 13, 2026

View reviewed changes

Merge branch 'dev_sprint_25_2' into feature/VPLAY-12164_http-404

4d6be34

Copilot AI review requested due to automatic review settings January 20, 2026 11:08

Copilot started reviewing on behalf of sayanurag January 20, 2026 11:08 View session

Copilot AI reviewed Jan 20, 2026

View reviewed changes

Merge branch 'dev_sprint_25_2' into feature/VPLAY-12164_http-404

62d4beb

sayanurag force-pushed the feature/VPLAY-12164_http-404 branch from 6098e5f to 62d4beb Compare January 20, 2026 11:16

Merge branch 'dev_sprint_25_2' into feature/VPLAY-12164_http-404

42b9a38

Copilot AI review requested due to automatic review settings January 21, 2026 20:48

Copilot started reviewing on behalf of pstroffolino January 21, 2026 20:49 View session

Copilot AI reviewed Jan 21, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

VPLAY-12164 Http 404 for mpd while channel change #845

VPLAY-12164 Http 404 for mpd while channel change #845

Uh oh!

sayanurag commented Jan 13, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

jfagunde Jan 13, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Jan 20, 2026

Uh oh!

Copilot AI Jan 20, 2026

Uh oh!

Copilot AI Jan 20, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Jan 21, 2026

Uh oh!

Copilot AI Jan 21, 2026

Uh oh!

Copilot AI Jan 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

-		if(mMPDDownloaderInstance != nullptr)
-		{
-			mMPDDownloaderInstance->Release();
+		AampMPDDownloader *mpdDownloader = NULL;
+		lock.lock();
+		mpdDownloader = mMPDDownloaderInstance;
+		lock.unlock();
+		if(mpdDownloader != NULL)
+		{
+			mpdDownloader->Release();

-		// stop the mpd update immediately after Stream abstraction delete
+		/*
+		 * DASH-specific teardown: explicitly stop MPD updates as soon as the
+		 * stream abstraction has been stopped/deleted.
+		 *
+		 * Rationale:
+		 * - When changing channels, the MPD downloader may still be running
+		 *   background manifest refreshes based on the old stream abstraction
+		 *   state (periods, adaptation sets, timelines, etc.).
+		 * - If the service reuses the same MPD URL for the new channel or if
+		 *   the old MPD becomes invalid while those refreshes are still in
+		 *   flight, the downloader can issue requests that no longer match
+		 *   the server state, leading to transient HTTP 404s during channel
+		 *   changes (as described in the PR).
+		 *
+		 * By releasing the MPD downloader here, immediately after
+		 * mpStreamAbstractionAAMP is torn down and only when downloads are
+		 * being disabled, we ensure that no further MPD refreshes are issued
+		 * based on stale stream state.
+		 *
+		 * Note:
+		 * - There is also a later mMPDDownloaderInstance->Release() call in
+		 *   Stop() (line 8107) which serves as a final safety net / global
+		 *   cleanup.
+		 * - This earlier Release() in TeardownStream is the intentional,
+		 *   protocol-aware shutdown point required to avoid the 404 bursts
+		 *   seen on rapid channel changes; the Stop()-level call must not be
+		 *   treated as a replacement for this one.
+		 */

VPLAY-12164 Http 404 for mpd while channel change #845

Are you sure you want to change the base?

VPLAY-12164 Http 404 for mpd while channel change #845

Uh oh!

Conversation

sayanurag commented Jan 13, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

jfagunde Jan 13, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Jan 21, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 21, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 21, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants